Method and system using dedicated location to share information between real mode and protected mode drivers

ABSTRACT

A computer method and system for providing protected mode device drivers that are compatible with real mode device drivers. A first aspect of the invention provides consistent assignment of drive unit numbers with which the same physical disks are accessed by the real mode and protected mode physical disk drivers. A second aspect of the invention provides consistent assignment of volume unit numbers with which the same logical volumes are accessed by real mode and protected mode logical volume drivers. A third aspect of the invention provides consistent assignment of adapter numbers with which the same adapters are controlled by real mode and protected mode adapter drivers and mapping real mode adapter driver requests to protected mode adapter driver requests of the protected mode adapter drivers that control the same adapters. A fourth aspect of the invention provides detection and protected mode accommodation of real mode functional drivers which are provided in addition to the real mode device drivers in the real mode operating system.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.08/184,668, filed Jan. 21, 1994, now U.S. Pat. No. 5,604,887.

TECHNICAL FIELD

The present invention relates to the field of device drivers and, moreparticularly, to an operating system which provides protected modedevice drivers.

BACKGROUND OF THE INVENTION

A typical computer system includes a computer that is interfaced with anumber of peripheral devices. The peripheral devices can be accessed byan operating system executing on the computer or by application programsexecuting on the computer via an appropriate interface. Such access tothe devices is controlled by software programs known as device drivers.Many device drivers, such as those provided by the Microsoft MS-DOSoperating system, are "real mode device drivers" which operate in aprocessor mode known as real mode. Real mode is the only mode ofoperation provided by the Intel 8086 microprocessor, on which theMicrosoft MS-DOS operating system was originally designed to execute.

More recent microprocessors such as the Intel 80826, 80386 and 80486,sold by Intel Corporation of Cupertino, Calif., are upwardly compatiblewith the 8086 and thus are designed to support real mode but they mayalso operate in an enhanced mode, known as "protected mode". Protectedmode provides benefits not provided by real mode. For instance,protected mode provides an enlarged virtual address space than providedby real mode. Protected mode also provides hardware support formultitasking and data security, which real mode does not. (Theprotection mechanism which provides data security in the 80386 and 80486is described in pp. 101-133 of "Microsoft's 80386/80486 ProgrammingGuide," published by Microsoft press, 1991.)

SUMMARY OF THE INVENTION

The present invention provides protected mode device drivers which arecompatible with real mode device drivers that access the same device.The protected mode device drivers are compatible with the real modedevice drivers in the sense that they use the same reference values toaccess the same devices. In a preferred embodiment, the inventionprovides an operating system capable of operating in protected mode andhaving the protected mode device drivers. During operation of theoperating system in protected mode, the protected mode device driversaccess the devices when so requested by the operating system or anapplication program. Real mode device drivers are also provided whichaccess the devices in real mode when requested by an operating system orapplication program that requires real mode operation. The protectedmode device drivers assign the same reference values to the devices asthe real mode device drivers assign to the same devices. The inventionensures compatibility with respect to these reference values byproviding multiple aspects of the invention, which are described below.

A first aspect of the invention provides consistent assignment of driveunit numbers with which the same physical disks are accessed by realmode and protected mode disk drivers. The real mode disk drivers whichaccess physical disks may not assign the same drive unit numbers tothose physical disks as the protected mode disk drivers which access thesame physical disks. The problem is that real mode disk drivers may havedifferent drive numbers than the drive numbers assigned to correspondingprotected mode disk drivers for BIOS INT 13 h interrupts. In the firstaspect of the invention, the preferred embodiment provides consistentassignment of the drive unit numbers with which the same physical disksare accessed via INT 13 h interrupts by both the real mode and protectedmode physical disk drivers. As a result, access to the same physicaldisks is provided by both the real mode disk drivers and protected modedisk drivers in a compatible fashion.

A second aspect of the invention provides consistent assignment oflogical volume unit numbers with which the same logical volumes areaccessed by real mode and protected mode volume drivers. The real modevolume drivers which control access to logical volumes on disks may notassign the same volume unit numbers to those logical volumes as theprotected mode volume drivers which control access to the same logicalvolumes. Specifically, the real mode volume drivers may have differentvolume numbers than the volume numbers assigned to correspondingprotected mode volume drivers for BIOS INT 25 h interrupts. In thesecond aspect of the invention, the preferred embodiment providesconsistent assignment of the volume unit numbers with which the samelogical volumes are accessed via INT 25 h interrupts by both the realmode and protected mode logical volume drivers. Thus, access to the samelogical volumes is provided by both the real mode volume drivers andprotect mode volume drivers.

A third aspect of the invention provides consistent assignment ofadapter numbers with which the same adapters are controlled by real modeand protected mode adapter drivers to access the peripheral devicesconnected to those adapters. The real mode adapter drivers which accessperipheral devices via adapters may not assign the same adapter numbersto those adapters as the protected mode operating system assigns toprotected mode adapter drivers that control the same adapters to accessthe same peripheral devices. In the third aspect of the invention, thepreferred embodiment provides consistent assignment of the adapternumbers with which the same adapters are controlled by both the realmode and protected mode adapter drivers to access the same peripheraldevices. The third aspect of the invention further provides mapping ofrequests to access the peripheral devices via real mode adapter driversto requests to access the peripheral devices via protected mode adapterdrivers which control the same adapters. Requests by applicationprograms to access the peripheral devices may be directed to the realmode adapter drivers even during operation of the protected modeoperating system unless otherwise directed. The preferred embodimentprovides mapping of application program requests to access theperipheral devices via real mode adapter drivers to requests to accessthe peripheral devices via protected mode adapter drivers which controlsame adapters.

The preferred embodiment further provides protected mode operation offunctions provided by real mode functional devices when the real modedevice drivers are executed. Thus, a fourth aspect of the inventionprovides detection and protected mode accommodation of real modefunctional drivers which have been provided in addition to the real modedevice drivers. Real mode functional drivers may have been added tosupplement the real mode device drivers by providing additionalfunctions. These functions may or may not be provided by any protectedmode functional drivers in the protected mode operating system. Unlessthese real mode functional drivers are accommodated by the operatingsystem when operating in protected mode, the protected mode devicedrivers will be incompatible with the real mode device drivers. In thefourth aspect of the invention, the preferred embodiment providesdetection and protected mode accommodation of the real mode functionaldrivers that are provided in addition to the real mode device drivers inthe real mode operating system. As a result of providing the above fouraspects of the invention, the preferred embodiment provides protectedmode device drivers which are compatible with real mode device driversand yet still reap the benefits of protected mode operation.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a typical computer system in which acomputer is connected to disk drives and other peripheral devices.

FIG. 2 is an illustration of the functional relationship among the realmode and protected mode device drivers and functional drivers and thedevices which they control.

FIG. 3 is an illustration of the functional relationship among the realmode disk drivers and protected mode disk drivers of the preferredembodiment of the present invention.

FIG. 4 is a flow diagram of the process of creating a drive table in thepreferred embodiment.

FIG. 5 is an illustration of the process of creating a drive table inthe contents of a portion of a master boot record of a disk in thepreferred embodiment.

FIG. 6 is an illustration of the drive table created in the preferredembodiment.

FIG. 7 is a flow diagram of the process of assigning a drive unit numberin the preferred embodiment.

FIG. 8 is an illustration of the functional relationship among the realmode volume drivers and protected mode volume drivers of the preferredembodiment.

FIG. 9 is a flow diagram of the process of building a volume table inthe preferred embodiment.

FIG. 10 is an illustration of a partition boot record and volume bootrecord of a volume on a disk in the preferred embodiment.

FIG. 11 is an illustration of the volume table created in the preferredembodiment.

FIG. 12 is a flow diagram of the process of assigning a volume unitnumber in the preferred embodiment.

FIG. 13 is an illustration of the real mode adapter drivers andprotected mode adapter drivers of the preferred embodiment.

FIG. 14 is a flow diagram of the process of building a real mode datastructure in the preferred embodiment.

FIG. 15 is an illustration of the real mode data structure created inthe preferred embodiment and unit specifies associated with each realmode data structure.

FIG. 16 is an illustration of peripheral data in each unit specifiercreated in the preferred embodiment.

FIG. 17 is a flow diagram of the process of creating data control blocksin the preferred embodiment.

FIG. 18 is an illustration of the data control block created in thepreferred embodiment.

FIG. 19 is a flow diagram of the process of assigning adapter numbers inthe preferred embodiment.

FIG. 20 is a flow diagram of the process of accommodating real modefunctional drivers in the preferred embodiment.

FIG. 21 is a flow diagram of the process of detecting a real modefunctional driver in the preferred embodiment.

FIG. 22 is an illustration of a data parameter block, the contents of aportion thereof and the real mode device drivers or functional driversspecified therein.

FIG. 23 is an illustration of an original driver structure in thepreferred embodiment.

FIG. 24 is an illustration of a safe driver list in the preferredembodiment.

FIG. 25 is a flow diagram of the process of adapting a real modefunctional driver in the preferred embodiment.

DETAILED DESCRIPTION OF THE INVENTION

The preferred embodiment of the present invention substitutes protectedmode device drivers for real mode device drivers whenever possible. Theprotected mode device drivers are implemented to be compatible with thereal mode device drivers. Specifically, the protected mode devicedrivers access devices are assigned reference values that identify thesame devices in the same fashion as the real mode device drivers. Thepreferred embodiment further provides, to the extent possible, protectedmode operation of functions provided by real mode functional deviceswhen the real mode device drivers are executed.

The above features are provided by four separate aspects of theinvention, described below. A first aspect of the invention providesconsistent assignment of drive unit numbers with which the same physicaldisks are accessed by real mode and protected mode disk drivers. Asecond aspect of the invention provides consistent assignment of logicalvolume unit numbers with which the same logical volumes are accessed byreal mode and protected mode volume drivers. A third aspect of theinvention provides consistent assignment of adapter numbers with whichthe same adapters are controlled by real mode and protected mode adapterdrivers to access the peripheral devices connected to those adapters.The third aspect of the invention further provides mapping of requeststo access the peripheral devices via real mode adapter drivers torequests to access the peripheral devices via protected mode adapterdrivers which control the same adapters. A fourth aspect of theinvention provides detection and protected mode accommodation of realmode functional drivers which are provided in addition to the real modedevice drivers.

A computer system suitable for practicing the preferred embodiment ofthe present invention is shown in FIG. 1. FIG. 1 is a block diagram of acomputer system having a computer 100 coupled to disk drives 110 andperipheral devices 120. The computer 100 has an internal memory 102which stores an operating system 210. The memory 102 also stores realmode and protected mode device drivers. These drivers may be part of theoperating system 210 or separate from the operating system. The devicedrivers are run on a central processing unit (CPU) 104 to control accessto the devices 110 and 120 as requested by the operating system 210 orby an application program. The device drivers include disk drivers andvolume drivers which control the disk drives 110 via an I/O controller106. The device drivers for the disks allow access to the physical disksand logical volumes on disks resident on the disk drives 110. The devicedrivers also include adapter drivers which control the adapters 108through which the peripheral devices 120 are accessed. The memory 102also stores real mode and protected mode functional drivers which areexecuted by the CPU 104 to add functional enhancements to the devicedrivers, such as encryption and data compression.

The functional relationship among the devices, device drivers andfunctional drivers in the preferred embodiment is illustrated in FIG. 2.The operating system 210 includes real mode (RM) device drivers 202 forthe peripheral devices 120. The operating system 210 also includesprotected mode (PM) device drivers 212 which control the same devices asthe real mode device drivers 202. In the preferred embodiment, theoperating system further includes real mode functional drivers 204 whichsupplement the real mode device drivers 202 and protected modefunctional drivers 214 which supplement the protected mode devicedrivers 212. The functional drivers 204 may be part of the devicedrivers 202. In the preferred embodiment, the operating system 210 iscomposed of an embellished version of the Microsoft WINDOWS 3.1operating system, sold by Microsoft Corporation of Redmond, Wash.,provided on a platform of the Microsoft MS-DOS 5.0 operating system,also sold by Microsoft Corporation. The Microsoft MS-DOS operatingsystem portion of the operating system 210 is loaded at boot time. TheMicrosoft WINDOWS operating system portion of the operating system 210is loaded thereafter. Although the MS-DOS operating system portion ofthe operating system 210 is capable of executing only in real mode, theMicrosoft WINDOWS operating system portion of the operating system 210is capable of executing in either real mode or protected mode.

In the first aspect of the invention, the preferred embodiment providesconsistency among the drive unit number mapping for hard disks by realmode device drivers 202 and the protected mode device drivers 212. Whena physical sector of a disk is accessed by either the real mode devicedrivers 202 or the protected mode device drivers 212, the real modedevice drivers 202 and the protected mode device drivers 212 must knowthe drive unit number of the disk drive to access the sector of thedisk. The operating system 210, includes as part of the MS-DOS operatingsystem a Basic Input/Output System software module (BIOS). The BIOScontains a set of predefined functions that may be called by operatingsystems or applications to perform tasks. The functions are called bysoftware interrupts. One such interrupt is the INT 13 h ("h" designateshexadecimal) interrupt. Typically, a volume driver employs the INT 13 hinterrupt to request the performance of various operations on a disk,that is identified by a drive unit number. The drive unit number isloaded into a processor register at the time of the interrupt.

In order for the protected mode disk drivers 310 (FIG. 3) to controlaccess to the physical disks 320 in a fashion compatible with the realmode disk drivers 300, the protected mode disk drivers 310 must assignthe same drive INT 13 h unit numbers as the real mode disk drivers 300assign to the physical disks 320. That is, for example, the drive unitnumber 0 assigned to a first hard disk for a real mode disk driver 300must also be assigned by the protected mode disk driver 310 for the harddisk, as is shown in FIG. 3. When the INT 13 h drive unit number 0 isspecified in a request to access a physical disk, via the real mode diskdriver 300 or the protected mode disk driver 310, the same disk 320 isaccessed by either disk driver which has assigned the drive unit number0 to the disk driver 110 that it controls. Similarly, the similar parityof INT 13 h unit number assignments must exist for the rest of the harddisks 320. This is not ensured by simply assigning the INT 13 h driveunit numbers to the protected mode hard disk drivers 310 in the orderthat the protected mode hard disk drivers 310 are loaded because theprotected mode hard disk drivers 310 do not necessarily load in the sameorder as the real mode hard disk drivers 300.

To ensure consistent drive unit numbers, as explained above, thepreferred embodiment first creates a drive table 600, which will bedescribed in greater detail with reference to FIG. 6 below. The drivetable 600 associates the drive unit number used by each real mode harddisk driver 300 with unique information stored on the physical hard diskaccessed by that real mode hard disk driver 300. The protected mode harddisk drivers 310 then assign the drive unit numbers to the same physicalhard disk 320 using the driver table. Each protected mode disk driverreads a selected portion of the physical disk to obtain the uniqueinformation and then extracts from the drive table the drive unit numberthat is associated with the unique information read from the physicalhard disk. The extracted drive unit number is then assigned to thephysical hard disk by the protected mode hard disk driver.

FIG. 4 is a flow diagram of the process which creates the drive tabledescribed above, referred to herein as the Build Drive Table process.The Build Drive Table process can be implemented as software stored inthe memory 102 and executed by the CPU 104 when the operating system 210is loaded. In step 405, the Build Drive Table process initializes to 0 adisk drive counter n, and all checksum flags (described in more detailbelow) in the drive table, are also initialized to 0. In step 410, theBuild Drive Table process initiates an INT 13 h interrupt to the CPU 104to read a first physical hard disk 320. The Build Drive Table processprovides the hard disk drive counter value n as the drive unit number(initially 0), a value which specifies that a read function is to beperformed, and the sector number of the sector in which the master bootrecord is stored on the disk. In step 415, the Build Drive Table processdetermines whether the master boot record read in step 410 is of astandard format used by the MS-DOS operating system 200. If so, alocation is provided on the hard disk in which a unique signature (whichwill be explained below) can be stored. The Build Drive Table processdetermines that the master boot record format is standard when byte DAhof the master boot record contains a value of zero. If the Build DriveTable process determines in step 415 that the master boot record read instep 410 is of the standard format, then control proceeds to step 420.

In step 420, the Build Drive Table process determines whether thesignature stored in a specific location of the master boot record has anon-zero value. FIG. 5 illustrates the master boot record (MBR) atsector 0 of the physical hard disk read in step 410, and the signatureprovided therein. The signature is provided at consecutive bytes DCh andDDh of sector 0. If the Build Drive Table process determines in step 420that the signature in the master boot record is a non-zero value,control proceeds to step 425. In step 425, the signature stored in bytesDCh and DDh is written into an entry in a drive table. FIG. 6illustrates the drive table into which the signature is written in step425. In FIG. 6, the drive table 600 contains a drive table entry 610 foreach disk drive 110. The drive table entry 610 contains a drive unitnumber field 612, a signature field 614 into which the signature waswritten in step 425, and a checksum flag 616. Control then proceeds tostep 430. In step 430, the drive unit number n is written into the driveunit number field 612 of the same drive table entry 610 in which thesignature was written into the signature field 614.

If the Build Drive Table process determines in step 420 that thesignature in bytes DCh and DDh of the master boot record is 0, thencontrol branches to step 435. In step 435, the Build Drive Table processdetermines whether the hard disk corresponding to the disk drive 110 iswrite-protected. If so, a new signature cannot be written onto the harddisk. If the Build Drive Table process determines in step 435 that thehard disk is not write-protected, then control proceeds to step 440. Instep 440, the Build Drive Table process creates a new, unique signatureand writes the new signature into bytes DCh and DDh of the master bootrecord.

If the Build Drive Table process determines in step 435 that the harddisk is write-protected, or if the Build Drive Table process determinesin step 415 that the master boot record is not of the standard format,then control branches to step 445. In step 445 the Build Drive Tableprocess computes a checksum of the contents of the first sector of thehard disk read in step 410. Control then proceeds to step 450 whereinthe Build Drive Table process writes the computed checksum into thesignature field 614 (FIG. 6) of the drive table entry 610 provided forthe disk drive 110. In step 455 (FIG. 4), a checksum flag stored in thechecksum flag field 616 of the drive table entry 610 for the hard disk110 (and initialized to 0), is set to 1. Control then proceeds to step430 in which, as explained above, the drive unit number n is writteninto the drive table 610 provided for the disk drive 110. Then, in step465, the hard disk drive counter n is incremented. Control then proceedsto step 470, which determines whether all hard disk drives 110 have beenprocessed. If not, the Build Drive Table process loops back to step 410.If so, the Build Drive Table process ends.

The drive table 600 created by the Build Drive Table process of FIG. 4is then used to determine the correct drive unit number to be used byeach of the protected mode disk drivers 310. FIG. 7 is a flow diagram ofthe process by which the protected mode disk drivers 310 assign thedrive unit numbers to the physical hard disks, referred to herein as theAssign Drive Unit Number process. The Assign Drive Unit Number processcan be implemented as software stored in the memory 102 and executed bythe CPU 104 when the operating system 210 is loaded, during the loadingof each protected mode disk driver 310 and after the Build Drive Tableprocess has been performed.

In step 700 of the Assign Drive Unit Number process, a protected modedisk driver 310 is loaded. Control then proceeds to step 705. Theprocess then determines whether the master boot record is standard ornot (step 701). If the master boot record is not standard, a checksum ofthe master boot record is calculated (step 702). The resulting checksumis used as an index into the driver table to locate a driver entrytable. In contrast, if the master boot record is standard, the AssignDrive Unit Number process reads the signature stored in bytes DCh andDDh of the master boot record of the physical hard disk (step 705).Control proceeds to step 710. In step 710, the Assign Drive Unit Numberprocess finds the drive table entry 610 that has in the signature field614 the signature read in step 705. Control then proceeds to step 715.In step 715, the drive unit number stored in the drive unit number field612 of the drive table entry 610 found in step 710 is extracted, and theextracted drive unit number is assigned to the physical hard disk by theloaded protected mode disk driver 310. Control then proceeds to step720, in which it is determined whether there are more protected modedisk drivers 310 to be loaded. If more protected mode disk drivers 310are to be loaded, control loops back to step 700. Otherwise, the routineends. As a result of the above process, the real mode disk drivers 300and the protected mode disk drivers 310 which control the same hard diskdrives 110 assign the same drive unit numbers to the same physical harddisks.

The second aspect of the invention will now be described. In the secondaspect of the invention, the preferred embodiment provides consistencyamong the volume unit numbers for logical volumes that are used by thereal mode device drivers 202 and the protected mode device drivers 212.A logical volume is all or a portion of a fixed storage medium such as adisk or tape. Each logical volume contains a self-sufficient file systemcontaining at least one directory with zero or more files, andcontaining all the information required to locate these files anddirectories. The operating system 210 and application programs refer toa logical volume with a logical drive letter, such as "A:", "B:" whenspecifying a file or directory stored thereon. Although often a logicalvolume corresponds to a disk drive 110, a disk may contain more than onelogical volume. When a logical volume is accessed by either the realmode device drivers 202 or the protected mode device drivers 212, thevolume unit number (which corresponds to a logical drive letter) must beknown in order to access the particular logical volume desired. The BIOSmodule, discussed above, provides an INT 25 h interrupt handler throughwhich an operating system or application program requests theperformance of a logical volume READ function which reads a specificlogical volume on a disk. The BIOS module also provides an INT 26 hinterrupt handler through which an operating system or applicationprogram may request a logical volume WRITE function which writes aspecific logical volume on the hard disk. When an INT 25 h READ or INT26 h WRITE is requested, the volume unit number must be specified toidentify the specific logical volume to be read or to be written.

Like the drive unit numbers discussed above, the volume unit numbers areassigned to the logical volumes by real mode device drivers 202 whichcontrol access to the logical volumes (real mode volume drivers) in anorder designated by the operating system (e.g., the MS-DOS operatingsystem, by Microsoft Corp.). When the operating system 210 is loadedthereafter, protected mode volume drivers are loaded which assign thevolume unit numbers to the same logical volumes which the protected modevolume drivers control. A block diagram illustrating this relationshipis shown in FIG. 8. In order for the protected mode volume drivers 810shown in FIG. 8 to be compatible with the real mode volume drivers 800,the protected mode volume drivers 810 must assign the same volume unitnumbers as the real mode volume drivers 800 assigned to the same logicalvolumes 830. Thus, as shown in FIG. 8, volume unit number 0 is assignedto a first logical volume by the real mode volume driver 800 and by theprotected mode volume driver 810 which access the first logical volume.Volume Unit Number 1 is assigned by the real mode volume driver 800 andby the protected mode volume driver 810 which access a next logicalvolume, and each subsequent logical volume is assigned a volume unitnumber of sequentially greater value, until the last volume unit numbern is assigned.

To provide the consistent assignment of volume unit numbers describedabove, the preferred embodiment first creates a volume table 1100, whichwill be described in greater detail with reference to FIG. 11 below. Thevolume table associates the volume unit number assigned by each realmode volume driver 800 with a unique serial number stored in the logicalvolume 830 accessed by that real mode volume driver 800. The protectedmode volume drivers 810 assign the volume unit numbers to the samelogical volume 830 using the volume table. Each protected mode volumedriver reads the unique serial number from the logical volume 830 viathe protected mode volume driver and extracts from the volume table thevolume unit number associated with the unique serial number read fromthe logical volume.

FIG. 9 is a flow diagram of the process which creates the volume tabledescribed above, referred to herein as the Build Volume Table process.The Build Volume Table process can be implemented as software stored inthe memory 102 and executed by the CPU 104 when the operating system 210is loaded. In step 900, the Build Volume Table process initializes tozero a logical volume counter m which will be described in more detailbelow. Control then proceeds to step 910. In step 910, the Build VolumeTable process initiates an INT 25 h interrupt. The logical volumecounter m is specified as the volume unit number. The Build Volume Tableprocess also specifies the logical sector of the logical volume storingthe volume boot record as an interrupt parameter. The INT 25 h interruptcauses a logical READ to be performed. The logical READ reads thedesignated logical sector having the specified volume boot record. Thislogical sector includes a unique serial number stored at a predeterminedlocation on the volume boot record. The location of the volume bootrecord and serial number stored therein is obtained as shown in FIG. 10.In FIG. 10, the master boot record (MBR) of the disk on which thelogical volume is provided contains a pointer to a partition boot record(PBR). The partition boot record contains a pointer to a first (VBR)which stores a serial number uniquely identifying a first logicalvolume. Where additional logical volumes are resident in the computersystem, the partition boot record contains a pointer to a secondpartition boot record, as shown. The second partition boot recordcontains a pointer to the second volume boot record, which contains adifferent serial number that uniquely identifies the second volume.Additional logical volumes are represented in the same fashion.

Control then proceeds to step 920. In step 920, the Build Volume Tableprocess writes the serial number obtained in the volume boot record intoa volume table 1100, which is shown in FIG. 11. The volume table 1100contains a volume table entry 1110 for each logical volume resident onthe computer system. Each volume table entry 1110 contains a volume unitnumber field 1112 and a serial number field 1114. The Build Volume Tableprocess writes the serial number into the serial number field 1114 ofthe volume table entry 1110 provided for the logical volume controlledby the real mode volume driver 800 to which the volume unit number m isassigned. Control then proceeds to step 930. In step 930, the BuildVolume Table process writes the volume unit number m into the volumeunit number field 1112 of the volume table entry 1110 into which theserial number was written in step 920. Control then proceeds to step940, in which the volume counter m is incremented. Then, in step 950, itis determined whether all of the logical volumes have been processed. Ifnot, control loops to step 900. If so, the Build Volume Table processends.

The volume unit numbers obtained are then assigned to the correctlogical volume. A flow diagram of the process by which the volume unitnumbers are assigned, called herein the Assign Volume Unit Numberprocess, is shown in FIG. 12. The Assign Volume Unit Number processshown in FIG. 12 can be implemented as software that is stored in thememory 102 and executed by the CPU 104 when the operating system 210 isloaded. In step 1200 of the Assign Volume Unit Number process, aprotected mode volume driver 810 is loaded. Control then proceeds tostep 1202. In step 1202, the assign protected mode volume number processreads the serial number (by the following the path from the master bootrecord to partition boot record to volume boot record) from the volumeboot record of the logical volume. Control then proceeds to step 1204.In step 1204, the Assign Volume Unit Number process locates the volumetable entry 1110 in the volume table 1100 which contains the serialnumber read in step 1202. In step 1206, the volume unit number stored inthe volume unit number field 1112 of the volume table entry 1110obtained in step 1204 is assigned to the logical volume by the loadedprotected mode volume driver 810. In step 1208, the Assign Volume UnitNumber process determines whether there are more volume boot records(VBR's) to process. If so, control loops to step 1200. Otherwise, theAssign Volume Unit Number process ends. As a result, the real modevolume drivers 800 and the protected mode volume drivers 810 use thesame drive unit numbers for the volumes which they access.

The third aspect of the invention will now be described. In the thirdaspect of the invention, the preferred embodiment provides consistencyamong the adapter numbers for the adapters 108 (FIG. 1). These adapternumbers are used by the real mode device drivers 202 and protect modedevice drivers 212 to control the adapters 108 to access the peripheraldevices 120 connected thereto. For example, the adapters 108 are SCSIadapters, and the MS-DOS operating system provides real mode SCSIadapter drivers. The SCSI adapter drivers include, for example, ASPI(Advanced SCSI Programming Interface) and CAM (Common Access Method)drivers. When the operating system 210 is loaded thereafter, protectedmode adapter drivers are provided which control the same adapters 108 asthe real mode adapter drivers.

A block diagram is shown in FIG. 13 which illustrates the relationshipamong the adapter drivers and the adapters 108 described above. For theprotected mode adapter drivers 1310 shown in FIG. 13 to control theadapters 108 in a fashion compatible with the real mode adapter drivers1300 that control the same adapters 108, the same adapter numbers mustbe assigned by the protected mode adapter drivers 1310 that the realmode adapter drivers 1300 assign to the same adapters 108. The adapternumbers are assigned by the real mode adapter drivers 1300 in an order.For example, when loaded by the MS-DOS operating system, the adapternumbers are assigned in the order that the real mode adapter drivers1300 are loaded. The operating system 210, however, does not necessarilyload the protected mode adapter drivers 1310 in the same order as thecorresponding real mode adapter drivers 1300. Thus, it cannot be ensuredthat the same adapter numbers will be assigned to the real mode adapterdrivers 1300 and the protected mode adapter drivers 1310 which controlthe same adapters 108.

Additionally, some application programs may request to use the real modeadapter drivers 1300, even when protected mode drivers are present. Astill further complication is that an interface mapper 1320 may beprovided which maps requests to access peripherals via a real modeadapter driver 1300 of one interface type (e.g., ASPI) to a real modeadapter driver 1300 of a different interface type (e.g., CAM). Thus,application program requests to access the real mode adapter driversmust be mapped to the protected mode adapter drivers 1310 which controlthe same adapters 108. Further, requests to access real mode adapterdrivers 1300 which are mapped by an interface mapper 1320 to adestination real mode adapter driver 1300 must also be mapped to aprotected mode adapter driver 1310 that corresponds to the destinationreal mode adapter driver 1300.

To provide consistent assignment of adapter numbers and mapping ofrequests to the correct protected mode adapter driver 1310, thepreferred embodiment first creates for each adapter 108 a real mode datastructure 1500, which will be described in greater detail with referenceto FIG. 15 below. The real mode data structure associates the adapternumber assigned by a real mode adapter driver 1300 to the adapter 108which the real mode adapter driver controls with peripheral informationobtained from each peripheral device 120 connected to the same adapter108. When an interface mapper 1320 is provided, the real mode datastructure also associates the adapter number and peripheral informationwith an interface type. The interface type defines the type of interfaceof the destination real mode adapter driver 1300 to which requests tothe real mode adapter driver 1300 are mapped by the interface mapper1320.

When the protected mode adapter drivers 1310 are loaded thereafter, adata control block 1800 is created for each peripheral device 120connected to an adapter 108. The data control block 1800 will bedescribed in greater detail with reference to FIG. 18 below. The datacontrol block contains peripheral information obtained from eachperipheral 120 via the adapter 108 controlled by the protected modeadapter driver 1310. The peripheral information in each data controlblock is then compared to the peripheral information stored in the realmode data structures 1500. When the peripheral information is the same,the adapter number is extracted from the real mode data structure 1500.The extracted adapter number is assigned to the adapter 108 connected tothe peripheral 120 for which the data control block is provided by theprotected mode adapter driver 1310 which controls that adapter 108.

In the case where an interface mapper 1320 is provided, the peripheralinformation in more than one real mode data structure may match theperipheral information in the data control block 1800. In such a case,the adapter number which corresponds to the destination real modeadapter driver 1300 is assigned to the adapter 108 connected to theperipheral 120 corresponding to the data control block by the protectedmode adapter driver which controls that adapter 108. This adapter numberis obtained from the real mode data structure that associates theadapter number with an interface type (i.e., the interface type of thedestination real mode adapter driver 1300).

A flow diagram of the process which creates the real mode datastructures described above, referred to herein as the Build Real ModeData Structures (RMDs) process, is shown in FIG. 14. The Build RMDsprocess can be implemented as software stored in the memory 102 andexecuted by the CPU 104. In step 1400, the Build RMDs processinitializes the interface type, adapter counter, peripheral counter, andreal mode data structure (all of which will be described in more detailbelow). In step 1402, the Build RMDs process provides an SCSI inquiryinstruction via the real mode adapter driver 1300 to which the adapternumber indicated by the adapter counter (initially 0) is assigned. TheSCSI inquiry instruction obtains peripheral information from theperipheral device 120 indicated by the peripheral unit counter(initially 0 for each adapter). Then, in step 1404, the Build RMDsprocess stores the peripheral information and the adapter numbertogether in a unit specifier corresponding to the peripheral 120 andassociated with the real mode data structure corresponding to theadapter 108.

The real mode data structure and unit specifier are shown in detail inFIG. 15. Each RMD 1500 contains a next RMD pointer 1502 and a unitpointer 1504. The next RMD pointer 1502 points to a next RMDcorresponding to a next real mode adapter driver 1300. The next realmode adapter driver 1300 is the adapter driver that was loaded nextafter the real mode adapter driver 1300 to which the RMD 1500corresponds. The unit pointer 1504 points to a first unit specifier 1510having a peripheral data field 1512 and a unit pointer 1514. The unitpointer 1514 points to a next unit specifier 1510 corresponding to anext peripheral device 120 connected to the adapter 108 that correspondsto the RMD 1500. The specific contents of the peripheral data field 1512are shown in FIG. 16. The peripheral data field 1512 contains peripheralinformation 1600 comprising a target ID 1602, a logical unit number1604, and a checksum 1606 obtained from the peripheral device 120 towhich the unit specifier 1510 corresponds. The peripheral data field1512 further includes an interface type 1610 and an adapter number 1620which corresponds to the adapter 108 to which the RMD 1500 corresponds.

After the peripheral information is stored in step 1404 of the BuildRMDs process, control proceeds to step 1406. In step 1406, the BuildRMDs process determines whether a real mode adapter driver 1300 has beencalled in performing the SCSI inquiry instruction which differs from theinterface type initially specified. For example, the interface type isinitially set to ASPI, such that the SCSI inquiry instruction is firstprovided via all real mode adapter drivers 1300 which are ASPI drivers.In such a case, the Build RMDs process initially determines in step 1406whether a real mode adapter driver 1300 having an interface type otherthan ASPI has been called. A real mode adapter driver 1300 having adifferent interface type is called whenever an interface mapper 1320 isprovided which maps requests to the real mode adapter driver 1300 to adifferent, destination real mode adapter driver 1300. If, in step 1406,the Build RMDs process determines that a different interface type hasbeen called, then control branches to step 1408. In step 1408, the BuildRMDs process stores the interface type of the destination real modeadapter driver 1300 as the interface type 1610 in the peripheral datafield 1512 of the RMD 1500, replacing the zero values initially storedin the peripheral data field 1512. The RMD 1500 into which the interfacetype is stored corresponds to the real mode adapter driver 1300 to whichthe adapter number represented by the adapter counter is assigned.

If, in step 1406, the Build RMDs process determines that a differentinterface type is not called, then control proceeds to step 1410.Control also proceeds to 1410 after step 1408 is performed. In step1410, the peripheral counter is incremented and the next unit specifier1510 is obtained. Control proceeds to step 1412. In step 1412, the BuildRMDs process determines whether all of the peripheral devices 120connected to the adapter 108 have been processed. Is so, control loopsback to step 1402. If not, control branches to step 1414, in which theadapter counter is incremented.

Control then proceeds to step 1416 wherein the peripheral counter isreset to 0 and the next RMD is obtained. In step 1418, the Build RMDsprocess determines whether all of the adapters 108 have been processed.If so, the Build RMDs process ends. If not, control branches to step1420, in which the Build RMDs routine determines whether the interfacetype of the last real mode adapter driver 1300 is ASPI. If so, then instep 1422 the Build RMDs routine determines whether all of the ASPIdrivers have been processed. If not, control loops to step 1402. If so,control proceeds to step 1424, in which the interface type is set toCAM. Control then loops to step 1402. If, in step 1420, the Build RMDsprocess determines that the interface type is not ASPI, then controlbranches to step 1426, in which the Build RMDs process determineswhether the interface type of the last real mode adapter driver 1300 isCAM. If so, control proceeds to step 1426, wherein the Build RMDsprocess determines whether all CAM drivers have been processed. If not,control loops to step 1402. If so, control proceeds to step 1430 whereinthe interface type is set to INT 4 B. Control then loops to step 1402.

The process which creates the device control blocks, referred to hereinas the Build Device Control Blocks (DCBs) process, is shown in FIG. 17.The Build DCBs process can be implemented as software stored in thememory 102 and executed by the CPU 104 when the operating system 210 isloaded. In step 1700, the Build DCBs process loads a protected modeadapter driver 1310. Control then proceeds to step 1705. In step 1705,the Build DCBs process scans the peripheral information via the loadedprotected mode driver 1310 from a peripheral device 120 connected to theadapter 108 which is controlled by the loaded protected mode adapterdriver 1310. Control then proceeds to step 1710. In step 1710, the BuildDCBs process stores the peripheral information scanned in step 1705 intoa device control block (DCB) corresponding to the loaded protected modeadapter driver 1310. The device control block (DCB) into which theperipheral information is stored is shown in FIG. 18. As shown in FIG.18, the device control block 1800 contains a target ID 1802 whichidentifies the peripheral device, a logical unit number 1804, and achecksum 1806 based on the peripheral information scanned from theperipheral device 120 connected to the adapter 108 controlled by theloaded protected mode adapter driver 1310.

Control then proceeds to step 1715. In step 1715, the Build DCBs processdetermines whether more peripheral devices 120 are connected to theadapter 108 which is controlled by the loaded protected mode adapterdriver 1310. If so, control loops to step 1700. Otherwise, controlproceeds to step 1720, in which the Build DCBs process determineswhether more protected mode adapter drivers are to be loaded. If theBuild DCBs routine determines in step 1720 that more protected modeadapter drivers 1310 are to be loaded, then control loops to step 1700.Otherwise, the Build DCBs process ends.

A flow diagram of the process which assigns the adapter numbers to theprotected mode adapter drivers 1310, referred to herein as the AssignAdapter Numbers process, is shown in FIG. 19. The Assign Adapter Numbersprocess may be implemented as software stored in the memory 102 andexecuted by the CPU 104. In step 1900, the Assign Adapter Numbersprocess initializes the DCBs 1800, the RMDs 1500 and the unit specifiers1510, which will be explained. In step 1902, a "matches" counter isinitially set to 0, which will also be explained. In step 1904, theperipheral information stored in a unit specifier 1510 of an RMD 1500 iscompared to the peripheral information stored in a DCB 1800. Controlthen proceeds to step 1906. In step 1906, the Assign Adapter Numbersprocess determines whether the peripheral information in the unitspecifier 1510 is the same as the peripheral information in the DCB1800.

If, in step 1906, it is determined that the peripheral informationmatches, control proceeds to step 1908. In step 1908, the matchescounter is incremented. Control then proceeds to step 1910, in which adestination flag indexed by the value of the matches counter isinitially set to be False. Control then proceeds to step 1912. In step1912, the adapter number stored in the unit specifier 1510 is assignedto a "Driver" variable indexed by the value of the matches counter. TheDriver variable tentatively contains the adapter number of the protectedmode adapter driver 1310 corresponding to the DCB 1800. Control thenproceeds to step 1914. In step 1914, it is determined whether aninterface type 1610 (a non-zero value) is stored in the peripheral datafield 1512 of the unit specifier 1510. The interface type 1610 isinitially a zero value, and is set to an interface type only when storedin step 1408 of the Build RMDs process in FIG. 14. Step 1408 is onlyperformed when an interface mapper 1320 has been provided which maps arequest to a real mode adapter driver 1300 to a different, destinationreal mode adapter driver 1300. If, in step 1914, it is determined that anon-zero value is stored as the interface type 1610 in the peripheraldata field 1512 of the unit specifier 1510, then control proceeds tostep 1916. In step 1916, the destination flag indexed by the value ofthe matches counter is set to True.

Control then proceeds to step 1922, in which the Assigned Adapter Numberprocess determines whether more unit specifiers 1510 correspond to theRMD 1500. If so, control proceeds to step 1924, in which the next unitspecifier 1510 is obtained, and control then loops to step 1902.Otherwise, control branches to step 1926, in which it is determinedwhether more RMDs 1500 are provided. If so, the next RMD 1500 isobtained and control loops to step 1902. Otherwise, control branches tostep 1930. In step 1930, the adapter number of the matching RMD isassigned to the adapter 108 to the protected mode adapter driver 1310corresponding to the DCB which matches that RMD. When more than one RMDmatched the DCB, the adapter number stored in the RMD that is associatedwith an interface type (that of the destination real mode adapterdriver) is assigned by the protected mode adapter driver 1310. Thisassignment can be illustrated by the following pseudocode:

    ______________________________________                                        if matches = 1                                                                then adapter number = Driver (matches)                                        if matches > 1                                                                then for n = 1 to matches                                                     if destination (matches) = True                                                        then adapter number = Driver (matches).                              ______________________________________                                    

Control then proceeds to step 1932, wherein it is determined whethermore DCBs are to be processed. If so, control proceeds to step 1934, inwhich the next DCB is obtained, and control then loops to step 1902. Ifnot, the routine ends.

In a fourth aspect of the invention, the preferred embodiment providesprotected mode accommodation of real mode functional drivers 204 whichhave been provided. In the fourth aspect of the invention, the preferredembodiment first detects the use of such real mode functional drivers204. The preferred embodiment determines whether the functionality ofthe detected real mode functional drivers 204 is provided by a residentprotected mode functional driver. If so, requests to the real modefunctional drivers are mapped to the protected mode functional drivers214. If not, the preferred embodiment adapts the real mode functionaldrivers 204 to work with the protected mode device drivers 212 insteadof the real mode device drivers 202.

The process which accommodates the real mode functional drivers,referred to herein as the Accommodate Real Mode (RM) Functional Driversprocess, is shown in FIG. 20. The Accommodate Real Mode FunctionalDrivers process may be implemented as software stored in the memory 102and executed by the CPU 104. In step 2000 of the Accommodate Real ModeFunctional Drivers process, the Accommodate Real Mode Functional Driversprocess performs a Detect Real Mode Functional Driver process whichdetects a real mode functional driver. The Detect Real Mode FunctionalDriver process is shown in FIG. 21. In step 2100 of the Detect Real ModeFunctional Driver process the Boolean value "detected" is initially setto False. Control then proceeds to step 2105. In step 2105, the DetectReal Mode Functional Driver process obtains current driver informationfrom a disk parameter block provided for a real mode logical driver.

The disk parameter block is shown in FIG. 22. As shown in FIG. 22, thedata parameter block 2200 contains current driver information 2202 and apointer 2204 to a first driver to execute. Initially, the pointer 2204in the data parameter block 2200 points to a real mode device driver2210 which controls a device 2220 also controlled by a protected modedevice driver 2230. Where a real mode functional driver 2240 has beenprovided to supplement the real mode device driver 2210, however, thecalls to be real mode functional driver 2240 are hooked such that thepointer 2204 points to the real mode functional driver 2240. In such acase, the current driver information 2202 describes the real modefunctional driver 2240 instead of the real mode device driver 2210originally described thereby. It should be appreciated that thefunctional drivers may be part of the real mode drivers rather thanseparate drivers.

Control then proceeds to step 2110. In step 2110, the Detect Real ModeFunctional Driver process obtains an original driver structure from theIO.SYS module. The IO.SYS software module is a well-known moduleprovided by the hardware manufacturer of the computer system to start upthe MS-DOS operating system 200. The original driver structure is shownin FIG. 23. The original driver structure contains a real mode drivername, a number of units controlled, and a real mode driver headeraddress. Control then proceeds to step 2115 in which the real modedriver name, a number of units controlled and the real mode driverheader address in the original driver structure 2300 are compared to thecurrent driver information corresponding to the same device 2220. Wherea real mode functional driver 2240 has been provided, the information inthe original driver structure 2300 will not match the current driverinformation 2202 in the data parameter block 2200. Thus, when in step2115 it is determined that the current driver information does notmatch, control proceeds to step 2120, wherein the "detected" flag is setto True. Otherwise, the detected flag remains False. The process thenreturns to continue performing the Accommodate Real Mode FunctionalDrivers process shown in FIG. 20.

After the Detect Real Mode Functional Driver process has been performedin step 2000 of the Accommodate Real Mode Functional Drivers process,control proceeds to step 2010. In step 2010, it is determined whetherthe detected flag was set to be True by the Detect Real Mode FunctionalDriver process. If so, control proceeds to step 2015. In step 2015, itis determined whether the real mode functional driver name is found in a"safe driver" list. The safe driver list is illustrated in FIG. 24. InFIG. 24, the safe driver list 2400 contains a list of real modefunctional driver names 2402. If, in step 2015, the real mode functionaldriver name is found on the safe driver list, then control proceeds tostep 2025. In step 2025, the Accommodate Real Mode Functional Driversprocess maps real mode functional driver requests to the protected modedriver identified in the safe driver list.

If the real mode functional driver name is not found in the safe driverlist in step 2015, then control branches to step 2030, in which theAdapt Real Mode Functional Drivers process is performed. Control thenproceeds to step 2035, wherein the Accommodate Real Mode FunctionalDrivers process determines whether more real mode logical drivers areprovided. If so, control proceeds to step 2040 in which the next realmode logical driver is obtained, and control then loops to step 2000. Ifnot, the Accommodate Real Mode Functional Drivers process ends.

FIG. 25 shows several of the major functional steps performed by theAdapt Real Mode Functional Driver process. This process is performed byexecuting software that is stored in memory 102 and executed by the CPU104. This process is invoked when the protected mode driver is not onthe safe driver list and, thus, the Real Mode Functional Driver must berelied upon to provide the desired functionality. Hence, as shown inFIG. 25, the logical requests to the protected mode driver are routedvia a real mode mapper to a real mode functional driver (step 2500).This request is then passed down the real mode driver chain until therequest reaches the last driver in the chain (step 2502). API calls bythe real mode driver are hooked into protected mode (step 2504). Thus,ASPI, CAM or INT 13 h API calls are hooked into protected mode. If thereare no API calls, there is no hook into protected mode.

Although the present invention has been described with reference to oneor more specific embodiments, it should be appreciated that variouschanges can be made by one of ordinary skill in the art withoutdeparting from the spirit of the invention. The scope of the inventionis Properly defined by the claims.

We claim:
 1. In a computer having a connection to a device, a processorthat can operate in real mode and protected mode, a real mode devicedriver for the device and a protected mode device driver for the device,a method comprising the steps of:(a) with the real mode device driver,assigning a unique reference value to the device that is accessed by thereal mode device driver; (b) accessing the device by the real modedevice driver, to read device information which uniquely identifies thedevice; (c) storing the reference value assigned to the device by thereal mode device driver in a memory location associated with the deviceinformation read from the device; (d) with the protected mode devicedriver, accessing the device to read the device information; (e)retrieving the reference value that was stored in the memory locationassociated with the device information; and (f) with the protected modedevice driver so that both the real mode device driver and the protectedmode device driver identify the device with the reference value,assigning the reference value obtained in step (e) to the deviceaccessed by protected mode device driver.
 2. The method of claim 1wherein step (c) comprises storing the reference value and the deviceinformation in a same entry in a data structure having an entry for eachdevice connected to the computer.
 3. In a computer having a connectionto a disk, a processor that can operate in real mode and protected mode,a real mode disk driver for the disk and a protected mode disk driverfor the disk, a method comprising the steps of:(a) with the real modedisk driver, assigning a unique drive unit number to the disk drive thatis accessed by the real mode disk driver; (b) accessing the disk driveby the real mode disk driver, to read disk information which uniquelyidentifies the disk residing on the disk drive; (c) storing the driveunit number identifying the disk in a memory location associated withthe disk information read from the disk; (d) with the protected modedisk driver, accessing the disk drive to read the disk information fromthe disk residing on the disk drive; (e) retrieving the drive unitnumber that was stored in the memory location associated with the diskinformation; and (f) with the protected mode disk driver, assigning thedrive unit number retrieved in step (e) to the disk drive accessed bythe protected mode disk driver.
 4. The method of claim 3 whereinstep (b)comprises reading a unique value stored on a predetermined location onthe disk as the disk information, and wherein step (c) comprises storingthe drive unit number with the unique value in a same entry in a tabledata structure having an entry for each disk drive connected to thecomputer.
 5. The method of claim 4, further comprising the steps of(g)determining whether the disk stores a unique value in the predeterminedlocation, and (h) writing the unique value into the predeterminedlocation if it is determined in step (g) that the disk does not store aunique value in the predetermined location.
 6. In a computer systemhaving a disk drive having a disk containing at least one logicalvolume, a processor that can operate in a real mode and a protectedmode, a real mode volume driver for accessing the volume on the disk anda protected mode volume driver, a method comprising the steps of:(a)with the real mode volume driver, assigning a unique volume unit numberto the volume accessed by the real mode volume driver; (b) accessing thevolume to read volume information which uniquely identifies the volume;(c) storing the volume unit number assigned to the logical volume by thereal mode volume driver in a memory location associated with the volumeinformation read from the disk; (d) with the protected mode volumedriver, accessing the volume to read the volume information; (e)retrieving the volume unit number stored in the memory locationassociated with the volume information read by the protected mode volumedriver; and (f) with the protected mode volume driver, assigning thevolume unit number obtained in step (e) to the disk accessed by theprotected mode volume driver.
 7. In a computer system having an adapterthat is connected to a peripheral device, a processor that can operatein a real mode and protected mode, a protected mode adapter driver forcontrolling the adapter and a real mode adapter driver for controllingthe adapter, a method comprising the steps of:(a) with the real modeadapter driver, assigning a unique adapter number to the real modedevice driver; (b) with the real mode adapter driver, scanning, from aperipheral device via the adapter, peripheral device information whichuniquely identifies the peripheral device; (c) storing the adapternumber assigned to the adapter in a memory location associated with theperipheral device information read from the peripheral device; (d) withthe protected mode adapter driver, controlling the adapter to access theperipheral device to scan the peripheral device information; (e)retrieving the adapter number stored in the memory location associatedwith the peripheral device information; and (f) with the protected modeadapter driver, assigning the adapter number obtained in step (e) to theadapter.
 8. In a computer system having a protected mode functionaldriver and a corresponding real mode functional driver, a method ofdetermining whether to execute a protected mode functional driverinstead of a real mode functional driver, the method comprising thecomputer-implemented steps of:(a) designating the protected modefunctional drivers as being executable instead of the corresponding realmode functional driver. (b) detecting the real mode functional driver inthe computer; (c) determining whether the protected mode functionaldrivers have been designated as being executable instead of the detectedreal mode functional driver; (d) executing the protected mode functionaldriver instead of the detected real mode functional driver when it isdetermined in step (b) that the protected mode functional driver hasbeen designated as being executable instead of the real mode functionaldriver.
 9. A computer system having;a computer with a processor and amemory and connected to one or more devices; a real mode device driverstored in the memory and executed by the processor, and assigning areference value to the device that the real mode device driver accesses;a protected mode device driver stored in the memory and executed by theprocessor; and means for the protected mode device driver to assign asame reference value to the device the protected mode device driveraccesses as the real mode device driver assigns to the same device. 10.The computer system of claim 9 whereinthe device comprises a disk driveon which a physical disk resides, the real mode device driver is a realmode disk driver which controls the disk drive to access the physicaldisk in real mode and the protected mode device driver is a protectedmode disk driver which control the disk drive to access the physicaldisk in protected mode, and wherein the means for the protected modedevice driver assigning the same reference value comprises the protectedmode disk driver assigning a same drive unit number to the disk drive asthe real mode disk driver which accesses the same physical disk.
 11. Thecomputer system of claim 10 wherein the means for the protected modedevice driver assigning the same reference value comprisesa drive tablehaving an entry for each real mode disk driver, the entry containing aunique value stored on the physical disk accessed by the real mode diskdriver and containing a drive unit number which has been previouslyassigned by the real mode disk driver, and means for the protected modedisk driver to assign the reference value contained in the entry to thephysical disk which stores the unique value also contained in the entry.12. The computer system of claim 9 whereinthe device comprises a diskdrive on which a logical volume resides, the real mode device driver isa real mode volume driver which controls the disk drive to access thelogical volume in real mode and the protected mode device driver is aprotected mode volume driver which controls the disk drive to access thelogical volume in protected mode, and wherein the means for theprotected mode device driver to assign the same reference valuecomprises the protected mode disk driver assigning a same volume unitnumber to the volume as the real mode volume driver which accesses thesame logical volume.
 13. The computer system of claim 12 wherein themeans for the protected mode device driver assigning the same referencevalue comprisesa drive table having an entry for each real mode volumedriver, the entry containing a unique value stored on the logical volumeaccessed by the real mode volume driver and containing a volume unitnumber which has been previously assigned by the real mode volumedriver, and means for the protected mode volume driver to assign thereference value contained in the entry to the logical volume whichstores the unique value also contained in the entry.
 14. The computersystem of claim 9 whereinthe device comprises an adapter to which one ormore peripheral devices are attached, the real mode device driver is areal mode adapter driver which controls the adapter to access theperipheral devices in real mode and the protected mode device driver isa protected mode adapter driver which controls the adapters to accessthe peripheral devices in protected mode, and wherein the means for theprotected mode adapter driver to assign the same reference valuecomprises the protected mode adapter driver assigning a same adapternumber to the adapter as the real mode adapter driver which controls thesame adapter to access the same peripherals.
 15. The computer system ofclaim 14 wherein the means for the protected mode adapter driverassigning the same adapter number comprisesa real mode data structureprovided for each real mode adapter driver, the real mode data structureassociating, for each peripheral attached to the adapter controlled bythe real mode adapter driver for which the real mode data structure isprovided, unique peripheral information scanned from the peripheraldevice connected to the adapter controlled by the real mode adapterdriver with an adapter number which has been previously assigned by thereal mode adapter driver, and means for the protected mode adapterdriver to assign the adapter number associated with the uniqueperipheral information to the adapter that accesses the peripheral fromwhich the unique peripheral information is scanned.
 16. In a computersystem connected to at least one system resource and capable ofoperating in a real mode and a protected mode, a method for a protectedmode device driver to use a same identifier to access a system resourceas an identifier used by a real mode device driver to access the samesystem resource, the method comprising the steps of:storing theidentifier for the system resource, associated with specific identifyinginformation obtained from the system resource, in a data structure;accessing the system resource by the protected mode device driver toobtain the specific identifying information; obtaining the identifierfor the system resource by the protected mode device driver from thedata structure, the identifier associated with the specific identifyinginformation obtained in the accessing step; and using the obtainedidentifier by the protected mode device driver to access the systemresource.
 17. In a computer system connected to at least one systemresource and capable of operating in a real mode and a protected mode, acomputer-readable storage device containing instructions for controllinga computer system to provide to a protected mode device driver a sameidentifier for accessing a system resource as an identifier used by areal mode device driver to access the same system resource, theinstructions for controlling a computer system implementing the stepsof:storing the identifier for the system resource, associated withspecific identifying information obtained from the system resource, in adata structure; accessing the system resource by the protected modedevice driver to obtain the specific identifying information; obtainingthe identifier for the system resource by the protected mode devicedriver from the data structure, the identifier associated with thespecific identifying information obtained in the accessing step; andusing the obtained identifier by the protected mode device driver toaccess the system resource.
 18. In a computer having a connection to adevice, a processor that can operate in real mode and protected mode, areal mode device driver for the device and a protected mode devicedriver for the device, a computer-readable medium holdingcomputer-executable instructions for performing a method comprising thesteps of:(a) with the real mode device driver, assigning a uniquereference value to the device that is accessed by the real mode devicedriver; (b) accessing the device by the real mode device driver, to readdevice information which uniquely identifies the device; (c) storing thereference value assigned to the device by the real mode device driver ina memory location associated with the device information read from thedevice; (d) with the protected mode device driver, accessing the deviceto read the device information; (e) retrieving the reference value thatwas stored in the memory location associated with the deviceinformation; and (f) with the protected mode device driver, assigningthe reference value obtained in step (e) to the device accessed byprotected mode device driver.
 19. The computer-readable medium of claim18 wherein step (c) comprises storing the reference value and the deviceinformation in a same entry in a data structure having an entry for eachdevice connected to the computer.
 20. In a computer having a connectionto a disk, a processor that can operate in real mode and protected mode,a real mode disk driver for the disk and a protected mode disk driverfor the disk, a computer-readable medium holding computer-executableinstructions for performing a method comprising the steps of:(a) withthe real mode disk driver, assigning a unique drive unit number to thedisk drive that is accessed by the real mode disk driver; (b) accessingthe disk drive by the real mode disk driver, to read disk informationwhich uniquely identifies the disk residing on the disk drive; (c)storing the drive unit number identifying the disk in a memory locationassociated with the disk information read from the disk; (d) with theprotected mode disk driver, accessing the disk drive to read the diskinformation from the disk residing on the disk drive; (e) retrieving thedrive unit number that was stored in the memory location associated withthe disk information; and (f) with the protected mode disk driverassigning the drive unit number retrieved in step (e) to the disk driveaccessed by the protected mode disk driver.
 21. The computer-readablemedium of claim 20 whereinthe step of determining whether the storedstatus of the first device has changed comprises repeatedly determiningwhether the status contained in the status field in the first deviceentry has changed; and the step of updating the stored status of thesecond device comprises updating the status in the status field in thesecond device entry when the status in the status field in the firstdevice entry changes.
 22. In a computer system having a disk drivehaving a disk containing at least one logical volume, a processor thatcan operate in a real mode and a protected mode, a real mode volumedriver for accessing the volume on the disk and a protected mode volumedriver, a computer-readable medium holding computer-executableinstructions for performing a method comprising the steps of:(a) withthe real mode volume driver, assigning a unique volume unit number tothe volume accessed by the real mode volume driver; (b) accessing thevolume to read volume information which uniquely identifies the volume;(c) storing the volume unit number assigned to the logical volume by thereal mode volume driver in a memory location associated with the volumeinformation read from the disk; (d) with the protected mode volumedriver, accessing the volume to read the volume information; (e)retrieving the volume unit number stored in the memory locationassociated with the volume information read by the protected mode volumedriver; and (f) with the protected mode volume driver, assigning thevolume unit number obtained in step (e) to the disk accessed by theprotected mode volume driver.
 23. In a computer system having an adapterthat is connected to a peripheral device, a processor that can operatein a real mode and protected mode, a protected mode adapter driver forcontrolling the adapter and a real mode adapter driver for controllingthe adapter, a computer-readable medium holding computer-executableinstructions for performing a method comprising the steps of:(a) withthe real mode adapter driver, assigning a unique adapter number to thereal mode device driver; (b) with the real mode adapter driver,scanning, from a peripheral device via the adapter, peripheral deviceinformation which uniquely identifies the peripheral device; (c) storingthe adapter number assigned to the adapter in a memory locationassociated with the peripheral device information read from theperipheral device; (d) with the protected mode adapter driver,controlling the adapter to access the peripheral device to scan theperipheral device information; (e) retrieving the adapter number storedin the memory location associated with the peripheral deviceinformation; and (f) with the protected mode adapter driver, assigningthe adapter number obtained in step (e) to the adapter.
 24. In acomputer system having a protected mode functional driver and acorresponding real mode functional driver, a computer-readable mediumholding computer-executable instructions for performing a method ofdetermining whether to execute a protected mode functional driverinstead of a real mode functional driver, the method comprising thecomputer-implemented steps of:(a) designating the protected modefunctional drivers as being executable instead of the corresponding realmode functional driver. (b) detecting the real mode functional driver inthe computer; (c) determining whether the protected mode functionaldrivers have been designated as being executable instead of the detectedreal mode functional driver; (d) executing the protected mode functionaldriver instead of the detected real mode functional driver when it isdetermined in step (b) that the protected mode functional driver hasbeen designated as being executable instead of the real mode functionaldriver.
 25. A computer-readable medium having computer executableinstructions for assigning a unit number to a peripheral device accessedby a protected mode driver, the unit number having already been assignedto the peripheral device by a real mode driver, which when executedperform steps comprising:(a) accessing the peripheral device with thereal mode driver and the unit number to write a signature to theperipheral device, the signature uniquely identifying the peripheraldevice; (b) storing the signature in a drive table; (c) storing the unitnumber in the drive table such that the unit number is associated withthe signature; (d) with the protected mode driver, accessing theperipheral device to read the signature from the peripheral device; (e)retrieving the unit number that was stored in the drive table associatedwith the signature; and (f) with the protected mode driver, assigningthe unit number retrieved in step (e) to the peripheral device accessedby the protected mode driver in step (d) so that both the real modedriver and the protected mode driver identify the peripheral device withthe unit number.